fix(release): fail loudly when GitHub release asset is missing#232
Open
fix(release): fail loudly when GitHub release asset is missing#232
Conversation
Hard-fail at startup if GITHUB_REPOSITORY is unset, and add a verification plugin that aborts semantic-release before publish if the release ZIP is not on disk. Closes a gap where @semantic-release/github silently ignores missing assets, which previously allowed releases to be published with no attached archive.
There was a problem hiding this comment.
Pull request overview
This PR hardens the GitHub Actions release flow to prevent publishing a GitHub release without the expected ZIP asset when the archive path is wrong or the archive step fails.
Changes:
- Fail early in
scripts/github/release.jswhenGITHUB_REPOSITORYis not set (instead of falling back tounknown). - Add a local semantic-release
prepareplugin that verifies./release/<repo>.zipexists before publishing. - Refactor the GitHub release asset path to use a single
releaseAssetPathvariable.
Reviewed changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 4 comments.
| File | Description |
|---|---|
| scripts/github/verify-release-asset.js | Adds a semantic-release prepare plugin to assert the expected ZIP archive exists before publish. |
| scripts/github/release.js | Enforces GITHUB_REPOSITORY presence and appends the verification plugin to prepare to avoid asset-less releases. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
Reject malformed GITHUB_REPOSITORY values (not in owner/repo form) so a value like "foo" no longer slips through and produces undefined.zip. Switch the verification plugin to utils.log for output consistency.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
All Submissions:
Changes proposed in this Pull Request:
@semantic-release/githubsilently ignores release assets whose path cannot be read on disk – it emits a single warning and then publishes the GitHub release anyway, with no attached archive. This is exactly what happened tonewspack-adsv3.10.2: the legacyscripts/release.jsinterpolatedprocess.env.CIRCLE_PROJECT_REPONAMEtoundefinedunder GitHub Actions, the asset path resolved to./release/undefined.zip, the file did not exist, and the v3.10.2 release shipped without a ZIP. The bug was only noticed after the release was already public.This PR closes that failure mode in
scripts/github/release.jsso a similar misconfiguration cannot silently produce an asset-less release again:GITHUB_REPOSITORYis unset, rather than falling back to the placeholder string'unknown'and producing anunknown.zipasset path that will never match anything on disk.scripts/github/verify-release-asset.js) is appended to thepreparelifecycle. It runs afterrelease:archiveis invoked bysemantic-release-version-bumpand throws if the expected./release/<repo>.zipis not present. Because it throws duringprepare, semantic-release aborts the run before thepublishlifecycle, so no GitHub release is created without the asset attached.The behavior on a successful release is unchanged – the verification plugin just logs an
OKline when the file is present.How to test the changes in this Pull Request:
The most realistic verification is a dry-run release in a consumer plugin. Using
newspack-ads(or any plugin that consumesnewspack-scriptsvia the reusable workflow) on a throwaway branch:newspack-scriptsdependency at this branch (github:Automattic/newspack-scripts#fix/release-fail-on-missing-asset) and runnpm install.releaseworkflow on a test branch, or runnpm run releaselocally withGITHUB_ACTIONS=true GITHUB_REPOSITORY=Automattic/newspack-adsset and a valid token). Confirm the new log line[verify-release-asset] OK: …/release/newspack-ads.zipappears and the GitHub release is published with the ZIP attached, exactly as before.release:archivescript (e.g. point its output at a different filename, or comment out thezipline). Re-run the release. Confirm semantic-release aborts duringpreparewith the errorRelease asset not found at …/release/<repo>.zipand that no GitHub release tag is created. This is the regression we are guarding against.GITHUB_REPOSITORY– Runnode scripts/github/release.js --files=newspack-ads.phpwithGITHUB_REPOSITORYunset. Confirm it exits with code 1 and prints theGITHUB_REPOSITORY is not setmessage before semantic-release is even constructed.bin/newspack-scripts.jsonly routes toscripts/github/release.jswhenGITHUB_ACTIONS=true, so the legacyscripts/release.jscode path is untouched.Other information: